1. Field of the Invention
The present invention relates generally to information processing environments and, more particularly, to improved methods for replication of transactions which are posted in a data processing system, such as a database management system (DBMS).
2. Description of the Background Art
Computers are very powerful tools for storing and providing access to vast amounts of information. Computer databases are a common mechanism for storing information on computer systems while providing easy access to users. A typical database is an organized collection of related information stored as “records” having “fields” of information. As an example, a database of employees may have a record for each employee where each record contains fields designating specifics about the employee, such as name, home address, salary, and the like.
Between the actual physical database itself (i.e., the data actually stored on a storage device) and the users of the system, a database management system or DBMS is typically provided as a software cushion or layer. In essence, the DBMS shields the database user from knowing or even caring about underlying hardware-level details. Typically, all requests from users for access to the data are processed by the DBMS. For example, information may be added or removed from data files, information may be retrieved from or updated in such files, and so forth, all without user knowledge of the underlying system implementation. In this manner, the DBMS provides users with a conceptual view of the database that is removed from the hardware level.
DBMS systems have long since moved from a centralized mainframe environment to a de-centralized or distributed environment. Today, one generally finds database systems implemented as one or more PC “client” systems, for instance, connected via a network to one or more server-based database systems (SQL database server). Commercial examples of these “client/server” systems include Powersoft® clients connected to one or more Sybase® Adaptive Server® Enterprise database servers. Both Powersoft® and Sybase® Adaptive Server® Enterprise (formerly Sybase® SQL Server®) are available from Sybase, Inc. of Dublin, Calif. The general construction and operation of database management systems, including “client/server” relational database systems, is well known in the art. See e.g., Date, C., “An Introduction to Database Systems, Volume I and II”, Addison Wesley, 1990; the disclosure of which is hereby incorporated by reference.
Each day more and more users base their business operations on mission-critical systems which store information on server-based database systems, such as Sybase® Adaptive Server® Enterprise. As a result, the operations of the business are dependent upon the availability of data stored in their databases. Because of the mission-critical nature of these systems, users of these systems need to protect themselves against loss of the data due to software or hardware problems, disasters such as floods, earthquakes, or electrical power loss, or temporary unavailability of systems resulting from the need to perform system maintenance.
One well-known approach for users to guard against loss of critical business data is to maintain a standby or replicate database. A replicate database is a duplicate or mirror copy of a given database that is maintained either locally at the same site as the primary database or remotely at a different location than the primary database. The availability of a replicate copy of a given database enables a user (e.g., corporation or other business) to reconstruct a copy of a given database in the event of the loss, destruction, or unavailability of the primary database. However, installing and maintaining a replicate copy of a given database requires a considerable investment in hardware, software, and services, particularly if the primary database is a large, mission-critical system handling large transaction volumes. Once a user has made the investment in the hardware, software and services necessary to install and maintain a replicate database, the user would like to be able to use the replicate database system for ancillary purposes such as decision support, reporting applications, and database backup. This allows for a better return on the user's investment in the replicate system hardware and software and also serves to reduce the operating load on the primary system.
Current disk mirroring technology can be used to create and maintain a replicate copy of a database. Disk mirroring technology creates a replicate database by replicating file-level changes in the file system used by the primary database to the file system used by the replicate database. However, a drawback of current disk mirroring technology is that the replicate copy of the database cannot be used while the disk mirroring system is actively updating the replicate file system. This impairs the use of the replicate database system for ancillary purposes such as decision support and reporting applications.
Another current approach for creating a replicate database involves the use of logical replication technology that can capture database changes at a primary database and apply those changes to a replicate database. Logical replication can be performed either asynchronously or synchronously. In an asynchronous logical replication system, a replication agent is used to read the database log and send the database operations to the replicate database. In this type of system, operations can be applied to the primary database before they are read from the log and sent to the replicate database. As a result, asynchronous logical replication does not guarantee that all the changes made to the primary database will be applied to the replicate database if the primary database unexpectedly stops working. In fact, asynchronous logical replication has some of the same limitations as trying to replicate a database from a tape backup. Many users regularly backup their databases to tape backup systems. A replicate (or copy) of the database can be constructed from this backup tape. However, any changes made to the database since the last backup was taken will be lost. Because users frequently require a replication methodology which guarantees that no database operations will be lost, asynchronous logical replication is unsuitable for many users. Another drawback of the asynchronous logical replication approach is that it results in latency between the time data is available at the primary database and the time it is available at the replicate database.
Synchronous logical replication guards against the problem of lost database operations by applying the operations at the replicate database at the same time that they are applied at the primary database. Synchronous logical replication operates in a manner similar to the two-phase commit protocol to ensure that operations are applied at both the primary and the replicate database. In addition, synchronous logical replication results in low latency between the time the data is available at the primary database and the time it is available at the replicate database. However, the “two-phase commit” approach of synchronous logical replication can drastically affect the performance of the primary database. This adverse performance impact makes the synchronous logical replication approach unsuitable for most applications.
As described above, existing solutions provide trade-offs in solving the various problems to be addressed in supporting a database environment that includes both primary and replicate databases. The problems to be addressed include avoiding data loss, reducing latency, improving performance, and increasing the availability of the replicate database. There is no current replication solution that guarantees that no database operations are lost, provides for low latency of the data being available at the replicate database, allows the replicate database to be continuously available, and still provides the performance necessary in today's computing environments.
What is required is a replication solution which guarantees that all transactions applied to the primary database are also applied to the replicate database, provides very little latency between the time data is applied to the primary database and the time it is applied to the replicate database, and makes the replicate database available to users while data is being replicated from the primary database. In addition, the solution should perform these tasks in a manner that does not adversely impair performance of the primary database system. The present invention provides a solution for these and other needs.